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BACKGROUND OF THE INVENTION 

The present invention relates to methods and systems 
5 for maintaining components of application programs in a 
client/ server network environment . A client is a personal 
computer or a workstation that operates on a network to 
execute various application programs. A server is 
typically a larger, centralized computer on the network 
10 which services the clients by providing programs, files and 
data, and by controlling hardware devices shared by the 
clients. 

An application program typically comprises a number 
of components each of which exists as a separately 

15 addressable file, and where each component is identified by 
a version number, perhaps indicating its creation date. An 
application program may typically undergo numerous 
revisions and updates throughout the course of its 
operational existence on the client. In the network 

20 environment, an application program on the client can be 
kept current by replacing one or more of such components, 
or by adding or deleting components. The components having 
the latest version numbers can be maintained on the central 
server and distributed from the server to each individual 

25 client as needed through a standard file transfer protocol. 
In the prior art systems, the version upgrading or 
component upgrading procedures are driven by the central 
server through complex interactions between the server and 
client systems. 




T 

-2- 

SUMMARY OF THE INVENTION 

Server-driven methods, however, are inherently 
unsuited for applications running on open-architecture 
networks, such as the Internet or intranet settings, in 
5 which the individual clients are difficult to access and 
control. The methods and systems of the present invention 
significantly improve the version updating process in a 
client-server environment in which such updating requires 
frequent and efficient deployment of the application 

10 components. In particular, the present invention shifts 
the version updating control to the individual client 
rather than the server, not only to reduce processing 
burden on the server but also to enable version updating in 
an open network environment, such as the Internet, where 

15 the source providing servers generally cannot control the 
remote clients. The methods of the present invention 
further adds security and protection from potential file 
corruption and undue delays during file transfer from a 
server to a client. By intelligently and automatically 

20 selecting to download and update only the needed and 

changed components of an application program, the present 
method alleviates the concerns of time and efficiency in 
any client-server network environment which requires highly 
dynamic application updates. 

25 In the preferred embodiment, the present invention 

involves maintaining on a server the components of an 
application program, each having a version identification, 
and maintaining a catalog of components with the version 
identifications. The components may include executable 

30 codes, library files, parameter files, and data files of 
the application program. The application program is 
further maintained at a client. In response to a call to 
the server from the client, the server is caused to 
download the catalog to the client and the client compares 

35 the version identifications between the components 
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maintained on the server as indicated in the downloaded 
catalog and the components maintained on the client. The 
application program on the client is updated by downloading 
from the server to the client the selected components for 
5 which the version identifications do not match. The 

updated application program is then executed on the client. 

The above preferred method further comprises updating 
the application program on the client by downloading from 
the server to the client the selected components specified 

10 in the catalog which are new and, therefore, not present on 
the client. This also makes possible the initial 
installation of the application on the client. Similarly, 
the catalog file can specify and cause to delete from the 
client any components previously included in the 

15 application program which are no longer needed to execute 
in the updated version. 

In the preferred embodiment, the catalog is used to 
specify: network addresses of other servers from which the 
catalog or component modules can be retrieved in subsequent 

20 updates; directory locations on the client for storing the 
downloaded components for proper execution of the 
application program on the client; and procedures for 
executing programs on the client, such as virus scanning 
code, after each component is downloaded as well as prior 

25 to and following the execution of the updated application 
program. 

In the preferred embodiment, the catalog file retained 
on the client specifies a maximum wait-time interval to 
limit any delay associated with updating the application 

30 program, and a list of further servers on the network, each 
including a copy of the catalog file. When, in response to 
the call to the server from the client, the server fails to 
download the catalog within the maximum wait-time interval, 
the client cancels the download and routes the call to one 

35 of the further servers to engage a new download and so on 
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until the catalog has been downloaded within the specified 
maximum wait-time interval. 

In the preferred embodiment, the catalog file is 
specified with a cryptographic digest for each component to 
5 ensure its authenticity and integrity. The client updates 
the application program on the client by downloading and 
replacing selected components for which the cryptographic 
digests do not match, and the client further computes the 
cryptographic digests on the client to ensure that each of 

10 the downloaded components is authentic and that each has 
not been corrupted during the download transmission. 

In the preferred embodiment, the frequency of the 
updating procedure is defined on a periodic basis or on an 
event-driven basis. For example, a predefined time 

15 interval, such as a day or week can be specified in the 
catalog, or by a user, and the application program is 
updated only on the first time the application is run in a 
specified time interval. In another embodiment , the 
application program on the client is automatically updated 

20 by an operating system or by a launcher program executed by 
a startup command on the client each time the client is 
booted up. In such an embodiment, the application program 
is caused to be updated regardless of whether the 
application program is executed at the client. Similarly, 

25 the client can be configured to update the application 
program periodically only as necessary to replace either 
outdated or corrupted components, or to delete any modules 
no longer needed, or to add any new modules. 

In the preferred embodiment, the call to the server 

30 from the client is transmitted to the server by a launcher 
program on the client which operates as a proxy to the 
application program. Selecting the application from the 
client to execute the program engages the launcher to 
communicate with the server, to cause the server to 

35 download the catalog file, and to update the application 
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program on the client and execute the updated application 
program on the client . In such an embodiment, the launcher 
can be implemented as a separate utility program or as a 
functional component of an operating system of the client 
5 and run invisibly in the background. 

Once the catalog file has been retrieved and processed 
in accordance with the method of the present invention, the 
status of each updating of the application program, 
including names of the components replaced, deleted or 

10 added on the client and related procedures, can be recorded 
in a file on the client for tracking and reporting the 
program usage and updates. Information in the downloaded 
catalog file, which at least includes the list of names and 
version identifications of the components for the updated 

15 application program, is stored on the client to be used in 
a subsequent update. The catalog file can also be 
specified to include a procedure to delete the components 
following the execution of the updated application program 
to free up disk space on the client. 

20 With the method of the present invention, controlling 

a version upgrade at the client through an open network 
environment, such as the Internet, can be easily 
implemented. In the Internet environment, for example, the 
call to a server for updating the application program can 

25 be made through a hypertext link on a Web browser directed 
to the catalog on the server. The launcher program can be 
integrated into the browser as a helper application, a 
plug-in module, or as a browser control. When the link is 
selected from the client browser, the launcher is executed 

30 to update the corresponding application components on the 
client. The downloading chores of the update can be 
accomplished through standard file transfer methods such as 
the file transfer protocol or the hypertext transfer 
protocol. The catalog file can also be specified to 

35 include a procedure to install on the client desktop an 
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icon or a shortcut which enables the end user to run the 
application without accessing the Web page in subsequent 
updates . 

The above and other features of the invention 
5 including various novel details of construction and 
combinations of parts will now be more particularly 
described with reference to the accompanying drawings and 
pointed out in the claims. These features are described 
with reference to installing and maintaining complete 

10 applications, but can also be used for individual 

components such as data files. It will be understood that 
the particular devices and methods embodying the invention 
are shown by way of illustration only and not as 
limitations of the invention. The principles and features 

15 of this invention may be employed in varied and numerous 
embodiments without departing from the scope of the 
invention. 



BRIEF DESCRIPTION OF THE DRAWINGS 

^Figure 1 is a graphical illustration of a closed 
20 network environment including a central distribution 
server, 

Figure 2A and 2B illustrate generally the client- 
controlled 'network environment of the present invention. 
Figure 3A illustrates the general framework in which 
25 the launcher program on a client controls a version update 
in conjunction with the procedure specified in the catalog 

^Figure 3 B illustrates the process involved in 
compos ing/^the preferred catalog file within the process as 
30 described in Figure 3A. 

Figure 3C is a graphical illustration of the user 
perspective^of the launcher driven client. 

Figure 3D is a graphical illustration of the version 




check process on the client. 
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Eigure^ 4A illustrates one embodiment of the launcher 
conf iguration . 

^Figures 4B to 4E illustrate the preferred embodiment 
of the launcher configuration and the detailed preferred 
updatafng process of the present invention. 

/ Figure/5 illustrates another aspect of the present 



invention^relating to^minimizing download wait time. 



Figures 6 A and 6B illustrate a further aspect of the 
present invention relatinct^to client configuration. 
10 Figures 7A through 7C illustrate preferred 

implementations of the methods of the present invention in 
the Internet environment. 



DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Referring to the drawings, Figure 1 illustrates a 

15 closed network 10 such as a local area network in which a 
central distribution server 12 controls the distribution of 
application software running on each of the multiple 
clients 14 within the network 10. In such an environment, 
the version updating typically requires the server 12 to 

2 0 undergo a complex task of updating each client 14 
individually. Such procedure requires significant 
processor power particularly if the clients must be updated 
at the same time. Further, a client program may be updated 
unnecessarily when the program is not routinely accessed at 

2 5 the client. 

In an open network architecture, such as the Internet 
and intranets, the centralized program updating is 
difficult due to the fact that the individual clients are 
not necessarily controlled by the server. In the Internet, 

30 for example, a Web server communicates with a remote client 
on an anonymous basis and cannot easily control the 
parameters of the client. Figure 2 A illustrates a 
preferred method of the present invention wherein a client 
22 controls the process of a software upgrade in the client 
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utilizing one or more servers 24 on a network. More 
particularly, in Figure 2B, a software version upgrade can 
be initiated through executing an application program on 
the client 22. The execution command transmits a request 
5 signal 23 to the server 24 which holds the latest 

application components. In the preferred embodiment, the 
server responds by downloading a catalog of a list of the 
application components, each identified with the latest 
version number. Here, the server includes either a single 

10 computer or multiple computers or other servers networked 
together. The catalog file is processed by the client 22 
to selectively identify and retrieve required components of 
the application program from the server 24. 

A persistent cache directory 22a on the client 22 

15 stores a representation of the catalog file 26, which at 
least includes the updated list of components and version 
numbers on the client, for a comparison in a subsequent 
version check. The components may either be stored in 
cache 22a or in program directories, such as 22b to 22d, 

20 specified in the catalog file 26, for proper execution. It 
can be seen that only the components which require updating 
are downloaded, and they are only downloaded when there is 
a need because the program is being accessed at the client. 
Figure 3 A is a preferred flow sequence of a version 

25 updating process of the present invention. The process 

first involves packaging a catalog file 300 in the server. 
The catalog file is downloadable from the server to a 
client using standard network transfer protocol, such as 
the file transfer protocol or the hypertext transfer 

30 protocol. In the preferred embodiment, as described in 
Figure 3B, a catalog file is prepared to include 
application information 320 which includes the client 
download directory location (s) and the execution command to 
the application program. For each component that is now 

35 required, the catalog file includes at 324 a version 
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identif ication, code or data size, and the network 
address (es) where the latest version of the component is 
stored. The components themselves may also be included 
within the catalog file in certain updating situations, 
5 For each component, a cryptographic digest is computed and 
specified in the catalog at 326. Such an encryption is 
used later to verify authenticity and integrity of the 
component following the completion of a download in the 
client. The catalog further includes at 328 for each 

10 component directory or subdirectory locations on the client 
where the component must reside in order to allow proper 
execution of the application program. 

Additionally, the catalog includes at 330 
identifications of components previously required in the 

15 application program that are now obsolete in the new 

version. At 34 0, the catalog file can also include the 
client's system environment variables relative to the 
installation requirements in different client directory 
locations. An environment variable is a system wide 

20 parameter commonly used to store small items of information 
to be shared between multiple programs. In one embodiment 
of the invention, certain environment variables hold 
references to directories in which application components 
are stored on the client. The catalog can also include at 

25 342, network locations storing future versions of the 

catalog file and/ or the associated application components. 
The catalog file can further include at 344 procedures 
necessary for executing codes after retrieval of each 
component or prior to and/or following the execution of the 

30 updated application program. 

Returning to Figure 3A, the catalog file is retrieved 
at 302 from the server in response to a call from the 
client. In a preferred embodiment, as illustrated in 
Figure 3C, the client 22 of the present invention includes 

35 a launcher program 348 which is automatically activated 
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when a user selects to run the application underlying icon 
350 on a desktop window 346 of the client system 22. The 
launcher 348 serves as a proxy to the application program 
and communicates with the server 2 4 over a network to 
5 request a download of the catalog file. 

In Figure 3A, the launcher processes the downloaded 
catalog file at 3 04 and begins to unpack the catalog file 
to initiate a version check at 306. The version comparison 
in these steps involves comparing the contents of a new 

10 catalog file 352 downloaded from the server, as shown in 
Figure 3D, with the existing representation of the catalog 
file 354 stored in persistent cache 22a of the client 22. 
The contents of the new catalog 3 52 reflect the latest 
component versions, and the catalog 354 in cache 22a lists 

15 the component versions presently installed on the client. 
The comparison described in these steps is only a basic 
requirement in an updating procedure. Other steps, as will 
be discussed later, can be specified in the catalog file 
and executed by the launcher on the client. 

20 Further referring to Figure 3A, the launcher at 308 

engages the server to download the required components for 
a proper update as defined in the catalog file in 306. The 
encrypted components are authenticated at 310 through the 
cryptographic digests specified in the catalog file. The 

25 pre-launch code prescribed in the catalog file, such as a 
virus scan, is executed at 312. The updated and verified 
application program is launched and executed at 314 
followed by any post-launch activities at 316 also defined 
in the catalog file. Information in the catalog file, 

30 which at least includes the updated list of components and 
version numbers on the client, is stored at 317 in cache on 
the client until the subsequent version update. 

The launcher program can be configured in different 
ways to accommodate users with different options to control 

35 and update the application program. In one embodiment, as 
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shown in Figure 4A, the launcher is a stand-alone program 
which can be executed through a desktop icon 400 on a 
client window. Selecting the icon executes the launcher 
program which provides a user with a dialog window to 
5 either select an existing application program to update at 
401 or specify the network address of the catalog file for 
a new application at 402. Through the launcher dialog 
window (s), a user can select any application program either 
to execute, or to update and execute, or simply to update 

10 the components therein. In another embodiment, as shown in 
Figure 4B, an icon directed to the application program can 
be installed on the client desktop window at 404. 
Selecting the icon automatically launches the launcher 
program in the background to begin an updating process. At 

15 405, the launcher program in this embodiment is pre- 

configured with network address (es) of the catalog file as 
a parameter of the program. 

Figures 4C through 4E further illustrate the preferred 
process of the present invention; In the preferred 

20 embodiment, a user may either invoke at 406 an icon 

directly associated with the application program or run the 
launcher program at 407 to select a particular application 
program to update. In either option, the launcher program, 
executes with the address of the catalog file to initiate 

25 program update at 408. At 409, the launcher retrieves the 
catalog file from the specified server address or from a 
local disk, and, at 410, the launcher reads the application 
information in the retrieved catalog file. The application 
information is as described in Figure 3B and includes the 

30 client download directory location (s) and the execution 

command and procedure relative to the application program. 
The catalog file is further examined for any environment 
variable pertaining to the client system which instructs 
the launcher as to how the components are installed on the 

35 client. At 414, the launcher designates appropriate 
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directories on the client where the components should be 
stored • 

The process for identifying the individual component 
files to download from the server begins at 416. At 416, 
5 the launcher reads the next component file name and version 
number or identification from the retrieved catalog file of 
the latest component versions made available on. the server. 
Each component version number is compared at 418 with the 
current component version numbers listed in a previous 

10 catalog file representation stored in cache on the client. 
If the version number is correct, the cryptographic digest 
is checked at 419. Any component not on the client or 
showing different version numbers or different 
cryptographic digest are selected and retrieved from the 

15 specified server location 4 20. The cryptographic digest is 
computed on a retrieved component at 421 and confirmed at 
422. An incorrect or a corrupted component is similarly 
replaced at 420. At 424, the launcher program executes any 
procedure such as virus scan decryption or expansion of 

20 encrypted or compressed component files specified in the 
catalog file after retrieving each component. 

Once the components have downloaded, any existing 
components on the client that are not no longer needed as a 
result of the version update are deleted at 430. At 432, 

25 information in the catalog file, which at least includes 
the list of the components of updated application program, 
is stored in cache on the client for use in a subsequent 
update. The launcher then executes at 434 the pre-launch 
procedures specified in the catalog, such as virus scan, 

30 prior to executing the application program at 436. The 

process completes by running the post- launch procedures at 
438. 

The catalog file can also be specified to include a 
procedure to delete the components following the execution 
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of the updated application program to free up disk space on 
the client. 

One aspect of the present invention relates to 
enhancing speed and efficiency with which an application 
5 program on a client is updated and executed so that the 
program runs with the most current data and/or coding 
structure. Figure 5 describes a preferred method of the 
present invention in which the client monitors and limits 
the time spent on an initial download of the catalog file 

10 from a server to a client. In the preferred embodiment, 

the catalog file previously stored on the client includes a 
maximum wait time interval specified as the time within 
which the transmission of the catalog file to the client in 
response to an application launch command should be 

15 completed. Such a time limit is to ensure that the catalog 
file is delivered quickly, and to identify and break a 
client-server communication jam which might delay the 
download indefinitely if the particular session were 
maintained. As indicated previously, the catalog file 

20 previously stored on the client includes the network 

addresses of alternate servers storing the catalog file. 
Referring to Figure 5, in response to an application launch 
from a client at 502, a timer is triggered to count down 
the maximum wait time interval specified in the catalog 

25 file at 504. While the catalog file is being retrieved at 
506 the timer is monitored against the maximum wait limit 
at 508. If the download has exceeded the time limit, the 
launcher in the client terminates the session and connects 
to a different server at 510 to initiate a new download. 

30 The timer is again activated, and the time limit is 
monitored until the download is completed at 514. 

Another aspect of the present invention relates to 
providing user flexibility at the client to control the 
updating procedures. In a preferred embodiment, as 

35 described in Figures 6A and 6B, a client can be configured 
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to adapt a number of different updating schedules. In this 
embodiment, an application program may be selected to run 
either from a client desktop at 602 or during a boot 
sequence at 611, and the associated launcher is 
5 automatically executed to run a sequence of parameter 
checks. At 604, if the launcher is configured to run an 
update on a periodic basis, such as on a daily, weekly, or 
monthly basis, the launcher, through an internal calendar 
or clock, checks to determine if a new update is due with 

10 respect to the last update at 608, and, if so, executes an 
update process once within such a period at 609. If the 
update is specified during a boot sequence 611, the 
launcher is executed at 612 during such boot and performs 
the version update at 614 typically without executing the 

15 application program. In all the other configured 
situations the client defaults to run the launcher 
automatically in each application launch, unless otherwise 
specified by the user or in the catalog file. In the 
defaults, sending the launcher can be implemented as a 

20 component part of the client operating system to run 
invisibly in the background. 

Yet another aspect of the invention relates to 
providing fully controlled client-server environment within 
an open network architecture, such as the Internet. In one 

25 preferred embodiment, as described in Figure 7A, the client 
is a World Wide Web (Web) client, such as a Web browser, 
and the automatic version upgrading process is implemented 
to run fully within such a browser. In this embodiment, a 
hypertext link at 704 to an application program is provided 

30 within a hypertext markup language (HTML) document 

displayed on a Web page. Such a link is a uniform resource 
locator directed to a server site which makes available the 
catalog file for download through either the file transfer 
protocol (ftp) or the hypertext transfer protocol (http) . 

35 The launcher program which receives and processes the 
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catalog file is embedded (706) into the browser as a "plug- 
in" module or as a native browser control. A plug-in 
module is an integrated component of a browser which 
enables the execution of non-Web applications within the 
5 browser environment. A native browser control is built 

into the browser, and is hence more tightly integrated than 
any add-on modules on separate executables. At 708, the 
launcher is engaged to process the downloaded catalog file. 
Accordingly the components are downloaded to update the 

10 application program without leaving the Web browser at 710 
and the program is executed at 712 . 

In another embodiment, the launcher program is 
implemented as a browser "helper application." In Figure 
7B, selecting the link directed to the catalog file on a 

15 Web page initiates the download and version check on the 
client at 716 to 720. The resulting updated application 
components are stored in the client cache directory or in 
the appropriate program directories 722. The updated 
application program can be executed either within the Web 

20 session or after exiting the Web browser at 726. The 

catalog file can also be specified to include a procedure 
to install on the client desktop an icon or a shortcut 
which enables the end user to run the application without 
accessing the Web page in subsequent updates. 

25 Figure 7C illustrates a preferred process in which a 

Web client, such as a Web browser, is configured not only 
to retrieve a component catalog file from a server but also 
to retrieve a launcher program to implement the update 
procedures on the client computer. At 728 and 730, a user, 

30 through a standard Web browser on a client, selects a link 
directed to the catalog file on a remote server. The 
browser, through a standard Internet protocol, such as 
hypertext transfer protocol, retrieves the catalog file at 
732 in response to the link. At 734, the browser is 

35 specified to query and determine whether the client 
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maintains a launcher program. If the launcher program is 
present on the client, the browser invokes the launcher at 
738 to begin the update process • In the event the client 
does not support a launcher, the browser is directed to 
5 download a launcher program from the server and to install 
the launcher integrally into the browser at 736. 

Equivalents 

While the invention has been described in connection 
with specific methods and apparatus, it is to be understood 
10 that the description is by way of example and not as a 
limitation to the scope of the invention as set forth in 
the claims. 



